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POLICY CHANGE CHARACTERIZATION METHOD AND APPARATUS 
Field of the Invention 

This invention relates to data communication networks. The invention relates 
to systems for fiacilitating the configuring of networks to provide desired levels of Quality of 
5 Service C'QoS") for data communication services on the networks. 

^af^fTr""P'* ''^^^^ Invention 

Maintaining efficient flow of information over data communication networks 
is becoming increasingly important in today's economy. Telecommunications networks are 
evolving toward a connectionless model from a model whereby the networks provide end-to- 

10 end connections between specific points. In a network which establishes specific end-to-end 
connections to service the needs of individual applications, the individual connections can be 
tailored to provide a desired bandwidth for communications between the end points of the 
connections. This is not possible in a connectionless network. The connectionless model is 
desirable because it saves the overhead implicit in setting up connections between pairs of 

15 endpoints and also provides opportunities for making more efficient use of the network 

infrastructure through statistical gains. Many networks today provide connectionless routing 
of data packets, such as Internet Protocol ("ff") data packets, over a network which includes 
end-to-end connections for carrying data packets between certain parts of the network. The 
end-to-end connections may be provided by technologies such as Asynchronous Transfer 

20 Mode ("ATM"), Time Division Multiplexing CTDW) and SONET/SDH. 

A Wide Area Network TWANT') is an example of a network in which the 
methods of the invention may be applied. WANs arc used to provide interconnections 
capable of carrying many different types of data between geogr^hically separated nodes. 
For example, the same WAN may be used to transmit video images, voice conversations, e- 
25 mail messages, data to and firom database servm, and so on. Some of these services place 
difiGerent requirements on the WAN. 

A typical WAN comprises a shared network which is connected by access 
links to two or more geographically separated customer premises. Each of the customer 
premises may include one or more devices connected to the network. More typically, each 

1 
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customer premise has a number of computers comiected to a local area network ("LAN"). 
The LAN is comeeted to the WAN access link at a service poim. The service point is 
grawrally at a "demarcation" unit or "interfece device" which collects data packets from the 
LAN which are destined fiar transmission over the WAN and sends those packets across the 
5 access link. The demarcation unit also receives data packets coming from the WAN across 
the access link and forwards those data packets to destinations on the LAN. One type of 
demarcation unit may be termed an ESP (Enteii^se Service Point). 

A network service is dependent on the amount of data it can send and receive 
fitsm a source device to one or more destination devices. Therefore, the quality of a network 
10 service is dependent on the amount of network resources (such as uptime, outages, 
bandwidth, delay, loss, and jitter) it can utilize to transfer its data. However, in a 
conventional IP network, all network services share all the network resources on a first come, 
first serve ("best effort") basis. This may be detrimental to some network services since some 
services require more network resources than other services. 

^ ^ Por example, a typical video conferencing service requires much more data to 

be sem than a typical e-mail service. Transmittiqg a video signal for a video conference 
requires feirly large bandwidth, short delay (or "latency"), small jitter, and reasonably small 
data loss ratio. An e-mail service requires fir less network resources than a video 
conferencing service because the e-mail service often has relatively little data to send to its 

20 destinations and it is generally acceptable if an e-mail transmission is sUghUy delayed in 

transiting a network. Transmitting e-mail messages or application data can generally be done 
with lower bandwidth but can tolerate no data loss. Furthermore, it is not usually critical that 
e-maU be delivered instantly, so e-mail services can usually tolerate longer latencies and 
lower bandwidth than other services. In addition, the e-mail service requires only enough 
25 network resources to send data in a single direction. Conversely, the typical video 
conferencing service requires enough networic resources to send data constantly and 
seamlessly in two directions. This may be required if all participants in the video conference 
want to see each other, thus requires an individual's image to be sent to the other participaiits 
and the other participant's images to be received. 

^the network resources are shared in a best efifortfishion between these and 
other types of network services, the e-mail service will deliver e-mail extremely &st, but the 

2 
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video conferencing service would not be able to display a very clear picture. What is desired 
is to have a policy where the network resources utilization is weighted such that the video 
conferencing service receives more networic resources than e-mail services. 

Typically, an enterprise which wishes to link its operations by a WAN obtains 
S an unallocated pool of bandwidth for use in carrying data over the WAN. While it is possible 
to vary the amount of bandwidth available in the pool (by purchasing more bandwidth on an 
as-needed basis), there is no control over how much of the available bandwidth is taken by 
each application. 

Again, guaranteeing the Quality of Service needed by applications which 
10 require low latency is typically done by dedicating end-to-end connection-oriented links to 
each application. This tends to result in an inefficient allocation of bandwidth, Networic 
resources which are committed to a specific link are not readily shared, even if there are 
times when the link is not using all of the resources which have been allocated to it. Thus 
committing resources to specific end-to-end links reduces or eliminates the ability to achieve 
15 statistical gains. Statistical gains arise from the fact that it is very unlikely that every 
application on a network will be generating a maximum amount of network traffic at the 
same time. 

If applications are not provided with dedicated end-to-end connections but 
share bandwidth, then each application can, in theory, share equally in the available 

20 bandwidth. In practice, however, the amount of bandwidth available to each application 
depends on things such as router configuration, the k>catton(s) where data for each 
^plication enters the network, the speeds at which the application can generate the data that 
it wishes to transmit on the networic and so on. The resuh is that bandwidth may be allocated 
in a manner that bears no relationship to the requirements of individual applications or to the 

25 relative importance of the applications. There are similar inequities in the latencies in the 
delivery of data packets over the network. 

The term "Quality of Service" is used in various different ways by different 
authors. In gmeral, QoS refers to a set of parameters which describe the required traffic 
cbaracteristica of a dau connection. In this specification, the term "QoS" generally refers to 
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a set of one or more of the following interrelated parametOT which describe the way that a 
data connection tr^ data packets generated by an application: 

•Minimum Bandwidth - a minimum rate at which a 
data connection must be capable of forwarding data originating from 
S the application. The data connection might be incapable of forwarding 

data at a rate fhster than the minimum bandwidth but should always be 
capable of forwarding data at a rate equal to the rate specified by the 
minimum bandwidth; 

• Maximum Delay- a maximum time taken for 
1 0 data from an application to completely traverse the data connection. 

QoS requirements are met only if data padcets traverse the data 
connection in a time equal to or shorter than the maximum delay; 

* Maximum Loss - a maximum fraction of data 
packets from the application which may not be successfiilly 

15 transmined across the data connection; and. 

Jitter- a measure ofhow much variation there is 
in the delay experienced by different packets from the application 
being transmitted across the data connection. In an ideal case, where 
all packets take exactly the same amount of time to traverse the data 
20 connection, the jitter is zero. Jitter may be defined, for example, as 

any one of various statistical measures of the width of a distribution 
funptipn ^^Mch expresses the probability that a packet will experience a 
paiticular delay in traversing the data connection. 

Diflforent applications require different levels of QoS. 

25 Recent developments in core switdies for WANs have made it possible to 

construct WANs capable of quickly and efficiently transmitting vast amounts of data. There 
is a need for a way to provide network users with control over the QoS provided to different 
data services which may be provided over the same networic. 
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Sendee providers who provide access to WANs wish to provide their 
customers with "Service Level Agreements" rather thui raw bandwidth. A Service Level 
Agreement is an agreement between a service provider and a customer that defines the level 
of service that wiU be provided for each particular type of application. This will permit the 
service providers to take advantage of statistical gain to more efficiently use the network 
infrastructure while maintaining levels of QoS that customers require. To do this, the service 
providers need a way to manage and track usage of these difTerent services. There is a 
particular need for relatively inexpensive apparatus and methods for fiurilitating the provision 
of services which take advantage of different levels of QoS. 



Applications connected to a network generate packets of daU for bansmisaion 
on the network. In providing different levels of service it is necessary to be able to sort or 
"classify" data packets from one or more appUcstions into different classes which will be 
accorded different levels of service. The data packets can then be trangmitted in a way which 
maintains the required QoS for each application. Data packets generated by one or more 
IS apptications may belong to the same class. 

Clearly, sharing all the network resources equally between the network 
services is not desired by a customer. A set of niles for allocaUng network resources between 
the various network services may be called a "policy". Policy management is meant to 
alleviate the uncontrolled network resouroes allocation between network services. The ability 
to configure the allocation of the network resources for the network services is called 
scheduling-based policy management. Scheduling-based policy management is preferred 
over priority-based policy management to be the policy architecture. Piioiity-based poUcy 
management means aU data packets of a particular network service are given a priority level 
over aU data packets of other network services. Scheduling-based policy management means 
that each network service is given a configurable amount of network resources over all other 
network services. A problem with implementirig scheduling-based policy manttgement occun 
when it becomes necessary to shift between difiisrent policies. This may require re- 
configuring a large number of network devices. TTiere is a need for methods and apparatus 
which will facilitate efficient change over from one policy to another. 



s 
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In the attached drawingB which illustrate non-limiting embodiments of the 

invention: 

5 Figure I is a schematic view of a wide area network according to the invention which 
comprises enterprise service point ("ESP") router devices according to the invention; 

Figure 2 is a schematic view illustrating two flows in a communications network 
accorcting to the invention; 

Figure 3 is a diagram illustrating the various data fields in a prior art IP v4 data packet; 
10 Figure 4 is a schematic diagram illustrating the stmcture of a possible policy tree 
according to the invention; 

Figure 5 is a schematic diagram illustrating an example of a possible policy tree according 

to the invention; 

Figure 6 is a schematic diagram illustrating the inheritance nature of classes in a policy 
15 tree; 

Figure 7 is a schematic diagram illustrating the mapping between a logical policy tree and 
its compiled or collapsed equivalent; 

Figure 8 is a schematic diagram illustrating scheduling classes and flow classes in a policy 

tree; 

20 Figure 9 is a schematic diagram illustrating how a class is defined and placed in a class 
repoutory and later copied into a policy tree; 

Figure 10 is a schematic diagram illustrating how a policy is defined and placed in a 
policy reporitory and later activated at a termination point; 

Figure 1 1 is a schematic diagram of a logical pipeline illustrating how a data packet is 
25 processed; 

Figure 12 is a schematic diagram illustrating how a policy is applied to both incoming and 
outgoing packets; 

Figure 13 is a schematic diagram illustrating the organization of logical pipeline 
components within an ESP; and 
30 Figure 14 is a schematic diagram illustrating how a policy can be put into service over an 
existing policy using incremental changes. 
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Detaited DMcrintion 

J 

This invention may be applied in many different situations where data packets are 
scheduled and dispatched. The following description discusses the qyplication of the 
invention to scheduling onward transmission of data packets received at an Enterprise Service 
5 Point CESP"") router device. The invention is not limited to use in connection with ESP 

devices but can be applied in almost any situation where classified data packets are scheduled 
and dispatched. 

Figure 1 shows a generalized view of a pair of LANs 20, 21 connected by a WAN 22. 
Each LAN 20, 21 has an Enterprise Service Point unit C*ESF') 24 which connects LANs 20, 

10 21 to WAN 22 via an access link 26. LAN 20 may, for example, be an Ethernet network, a 
token ring network or some other computer installation. Access link 26 may, for example, be 
an Asynchronous Transfer Mode C'ATM") link. Each LAN has a number of connected 
devices 2S which are capable of generating and/or receiving data for transmission on the 
LAN. Devices 28 typically include network-connected computers. The invention is not 

IS limited to data communications between LANs and WANs, but can also be applied to data 
communications between two LANS or two WANs or any other situation where classified 
data packets are scheduled and dispatched. 

As required, various devices 28 on network 20 may establish data connections with 
devices 28 of network 21 over WAN 22 and vice versa. A single device may be nmning one 

20 or more applications each of which may maintain uni-directional or bi-directional 

connections to applications on another device 28. Each connection may be called a session. 
Each session comprises one or more flows. Each flow is a stream of data from a particular 
source to a particular destination. For example, Figure 2 illustrates a session between a 
computer 28 A on network 20 and a computer 2SB on network 21. The session comprises 

25 two flows 32 and 33. Flow 32 originates at computer 28A and goes to computer 28B through 
WAN 22. Flow 33 originates at computer 28B and goes to computer 28A over WAN 22. 
Most typically data in a great number of flows will be passing through each ESP 24 in any 
period. ESP 24 manages the outgoing flow of data throu^ at least one port and typically 
through each of two or more ports. 

30 Each flow consists of a series of data packets. In general, the data packets may have 

different sizes. Each packet comprises a header portion which contains information about the 

7 
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packet and a payload or datagram. For exatnple, the packets may be Internet protocol CJF') 
packets. 

Figure 3 illustrates the fiDrmat of an IP packet 35 according to the currently implemented 
IP version 4. Padeet 35 has a heado* 36 and a data payload 98. The header contains several 
5 fields. The "version" field contains an integer which identifies the version of IP being used. 
The current IP version is vmion 4. The "header length** field contains an integer which 
indicates the length of header 36 in 32-bit words. The Type of Service" field contains a 
number which can be used to indicate a level of Quality of Service required by the packet. 
The ''total length'* field specifies the total lei^h of packet 35. The ""identification" field 

10 contains a number which identifies the data in payload 38. This field is lised to assemble the 
firagments of a datagram which has been broken into two or more packets. The 'flags'* field 
contains 3 bits which are used to determine whether the packet can be fi^agmented. The 
'time-to-live" field contains a number which is decremented as the packet is forwarded. 
When this number reaches zero the packet may be discarded. The ''protocol" field indicates 

15 which upper layer protocol applies to packet 35. The ''header checksum" field contains a 
checksum which can be used to verify the integrity of header 36. The "source address" field 
contains the IP address of the sending node. The "destination address" field contains the IP 
address of the destination node. The "options" field may contain information related to 
packet 35. 

20 Each ESP 24 receives streams of packets fiom its associated LAN and fi'om WAN 22. 

These packets typically belorig to at least several different flows. The combined bandwidth 
of the input ports of an ESP 24 is typically greater than the bandwidth of any single ou^ 
port of ESP 24. Therefiore, ESP 24 typically represents a queuing point vAere packets 
belonging to various flows may become backlogged while waiting to he transmitted through 

25 a port of ESP 24. Backlogs may occur at any output port of ESP 24. While this invention is 
preferably used to manage the scheduling of packets at all output ports of ESP 24, the 
invention could be used at only selective output ports of ESP 24. 

For e^cample, if the output port which connects ESP 24 to WAN 22 is backlogged, then 
ESP 24 must detmnine which packets to send over access link 26, and in which order, to 

30 make the best use of the bandwidth available in access link 26 and to provide desired levels 
of QoS to individual flows. To do this, ESP 24 must be able to classify each packet, as it 
arrives, according to certain rules. ESP 24 can then identify those packets vAiich are to be 

8 
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given priority access to link 26. After the packets are classified they caa be scheduled for 
transmission. Typically, all packets in the same flow are classified in the same class. 

Incoming packets are sorted into classes according to a policy which includes a set of 
rules. For each class, the rules specify the propeities which a data packet must possess for 
S the data packet to belong to the class. The policy preferably also has attributes for eadi class 
establishing QoS levels for that class. Therefore, each class contains rules and attributes, 
where rules define the identity of the data packet and the attributes define the amount of 
resource access and usage to route the data packet out of the ESP 24. 

As each new packet arrives at ESP 24 fi'om LAN 20 the new packet is classified. 
10 Classification involves extractir^g information intrinsic to a packet such as the source address, 
destination address^ protocol, and so on. Classification may also involve information external 
to the data packets such as the time of day, day of week, week of the year, special calendar 
date and the poit at which the packet arrives at ESP 24. This information^ wkdch comprise a 
set of parameters for each packet, is used to classify the packet according to a set of rules. 
15 The application of rules to a given packet to determine the ^propriate class is called "class 
identification*\ 

If the header 36 and/or external information of a data packet satisfies the rules of a class, 
then the data packet is identified as the type of service the class represents. For example, 
consider the rule for a class representing HTTP traffic: 
20 (Source port = 80) or (Destination port ^ 80) 

If the source port in the header 3£ in a data padcet is equal to 80, then the data packet is 
classified as HTTP traffic. 

Again, a class contains rules and attributes where: (i) rules define the identity of the data 

2S packet and (li) the attributes define the amount of resource access and usage to route the data 

packet out of the ESP. Since the ESP preferably uses scheduling-based policy management, 

the classes in a policy will be oriented towards traffic classification. Two broad categories 

of traffic classification are: 

real time; and 

30 • best effort. 

A group of classes rqiresents how the data packets of a set of network services will be 

ordered out of a termination point, a 'termination poinf ' in this context meaning the logical 

representation of the termination of any tran^ort entity such as a logical output port. This 

9 
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grouping of classes may be called the "TP policy'' since the relation of the classes to one 
another requires the definition of a policy in respect of that termination point. 

If the network service type of each class is completely different and with no overlap (i.e. 
"orthogonal'') to all the others, this would create a flat organization of classes. However, 
S classes can be refined such that classes do not have to be orthogonal to each other. For 
example, a class specifying a range of source and destination addresses can be refined by a 
class specifying a narrows range of source and destination addresses. Since classes can be 
refined, the class organization becomes a tree hierarchy (called a **policy tree") rather than a 
flat organization. 

10 Figure 4 schematically illustrates a typical policy tree 40. The root of the tree hierarchy 
is the TP policy 42 (typically represented by a triangle) and the nodes of the tree are classes 
44, 46, 48, SO, 52. 54. 56 (each typically represented by a circle). The leaves (i.e. nodes 
having no children) of the tree hierarchy are classes that are orthogonal to all the other leaf 
classes. For example, in Figure 4. the leaf classes 46, 48, SO, 54, 56 are orthogonal to one 

1 5 another. Furthermore, each class in a particular level or layer of the policy tree will be 

orthogonal to all other classes in that particular level or layer. In Figure 4, classes 44 and 46 
in the first layer are orthogonal to each other, classes 48, SO, 52 in the second layer are 
orthogonal to one another, and classes 54 and ^ in the third layer are orthogonal to each 
otha*. 

20 Each of the classes in a typical TP policy conuins the name of the class, the type of the 
service, and the amwnt of bandwidth it uses. Note that for best effort classes a percentage of 
the bandwidth is specified, whereas for real time a numerical value is used. This is because 
real time classes must specify the maximum amount of bandwidth, vAereas best effort classes 
must specify the minimum amount of bandwidth. 

2S Figure 5 schematically illustrates a specific example of a policy tree in practice. It is 

important to note that a dass will always refine its parent's rules and attributes. A class 
cannot provide rules or attributes that break its parent's set of rules and attributes. Each class 
in a policy tree can be thought of as containing its own attribiites and rules and virtually its 
parent's attributes and rules. This has a rewrsive effect such that a class has all the attributes 

30 and rules of its parent and its parent's parent all the way up to the root of the policy tree. This 
notion is called "inheritance". A class inherits all of Hb parent class's attributes and rules up 
to but not includirig the root of the policy tree. 

10 
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Figure 6 schematically illustrates the inheritance nature <tf classes in one branch of a 
policy tree. As ilhistnued in Figure 6, class B inherits all the attributes and rales of class A. 
Class C inherits all the attributes and rules of class B, which implies that class C also inherits 
all the attributes and rules of class A. 
5 The component within the ESP 24 that identifies the data packets as they flow through 

the ESP 24 is the class identifier. The class identifier may classify packets by using a logical 
lookup table caUed the "class lookup table" or "CLT' to identify the type of a data packet and 
map it to a class ID generated from the logical policy tree. In order to map the class 
identification of a logical policy tree to the CLT. the logical view of the policy tree is 
"collapsed" or "compiled" into a flat structure. Only classes that do not have children in the 
logical view will exist in the compiled view. These classes wUl contain all the rules required 
for the CLT. Figure 7 illustrates the mapping between a logical policy tree and a con^iled 
policy tree. In Figure 7, it can be seen that policy tree 60 can logically be compiled into 
policy tree 62, and that policy tree 62 is the flat-structure logical equivalent of policy tree 60. 

Each class in the policy tree represents a specific type of network service and how much 
network resources will be allocated to its data packets; in other words, each class defines a 
level of QoS to be assigned to data packets in that class. The data packets are placed into 
queues or "flows" that conespond to a leaf class in the policy tree. A single flow corresponds 
to a pattiailar session (such as a TCP/IP session). A flow may also be considered a grouping 
20 of packets that belong to the same flow of traflSc between two end points in a session. There 
are a configurable number of flows within each class. 

From a logical point of view, there can be a naming convention of classes that map to the 
physical point of view. Por example, a class that has no children may be called a "flow class" 
because it logically contains the flows where packets are queued. A doss that has children is 
25 called a "scheduling dass" because these classes define how the packeU will be scheduled 
out of the termination point. This naming convention is iUustrated in Figure 8, which depicts 
a class sub-tree where each leaf class is labelled as a flow dass and each non-leaf class is 
labdled as a scheduling dass. The difference between flow dasses and scheduling classes is 
also illustFBted in Figure 7; it can be seen in Figure 7 that the compiled policy tree 62 that is 
ultimatdy used by the dass identifier consists soldy of flow dasses^ and that the scheduliqg 
dasses in the equivalent uncompiled policy tree 60 are merely for directing the data packet to 
the propo- flow class. 
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Each scheduling class will dways have at least two children classes, one of which must 
be a flow class called the "default sibling class", which holds the flows that match the parent 
class but none of the other sibling classes. In mathematical terms, the defiuih sibling class is 
the "logical not" of all the other sibling classes. Every TP poUcy wUl have at least one 
5 defiiult class, which will be a best efibrt class that will be equivalent to the conventional 
m^od of managing traffic. 

The propeities of a flow class will be difiFerent than the properties of a scheduling dass. 
Specifically, the properties of a flow class will deal with scheduling as well as flow 
information (for example, how flows are allowed and how many data packets can be queued 
in a single flow). The properties of a scheduling class deal only with how to sdiedule data 
packets out of the tenninatibn point (for example, the bandwidth distribution). 

Classes are editable when created. After aU modifications to a class are completed, the 
class must be "committed", meaning it is voified and saved. Users can create and store 
classes and class sub-trees in a "class repository", which can be thought of as a logical 
15 storage facility tor classes and dass sub-trees. Classes may then later be copied from the 
class repositoiy and placed in a policy tree. The class reposttoiy is a usefUl tool for efficient 
policy tree creation and modification. It allows devdopm of graphical user inter&ces to 
create "drag and drop" fiinctionality. Figure 9 schematicdly illustrates how a leaf Class A is 
defined and placed in a class rq>ositoiy 64, and then later copied into a policy tree 66. 

A TP policy within an ESP 24 is defined in the context of the component that sends data 
packets out, namdy. a logicd output port. For each ESP 24. there are typically multiple 
logical output ports. A single logicd output port is associated with a single termination point 
and TP policy. Li turn, a TP policy is defined in terras of a policy tree of dasses that are 
logically assodated with a tennination point to schedule traiTic flowing out through an output 
25 port. The following are tyjpes of logicd output ports that an ESP 24 might handle: 
•Ethernet (4 physicd ports) 

•Tl/El or voice over DP card (2 physicd ports creating 48 voice channels but treated 
as a single logicd output port) 

•ATM (1 4xTl creating 4 physicd ports creating up to 256 logicd ports) 
Since the Ethernet has four logicd ports, the vdce over IP card has essentidly 1 port and 
the ATM has up to 2S6 logicd ports, there are typicdiy at most 261 TP policies bdng used in 
an ESP 24 which is configured in this manner at any particular moment. A voice over IP 
card is a speaal case fbr policy management since it only deds with red time voice traffic. 
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In this case, the voice over IP logical output port will have only one real time class in the 
policy tree. The feet that polides are associated only with the outpot port implies that a 
policy can be associated with the outgoing flow of data packete from any of: 

•LAN to WAN; 
5 -WAN to LAN; 

•LAN to LAN; and 
•WAN to WAN. 

Preferably there is always a defimh IP policy that is used when no TP policy is 
associated with a logical output port. The default TP policy contains only the default class. 

10 which is a best effort class. 

Each class must be verified with respect to all other classes within a TP policy so that 
there are no conflicts when the TP policy is in-service. Further, each TP policy put into 
service must be verified against aU other TP policies that will be in service at the same time. 
Consequently, all cteses in all TP poUcies that are put into seivice must be verified against 

15 each other to ensure that there are no conflicts in the CLT. This is required to prevent 

conflicts when the class identifier component decides which logical output port a data packet 
should go out of. For example, suppose two classes in two separate TP policies has 8 single 
rule: 

-source IP address = 111. 111.111111/16" 
This would mean that the CLT would have two entries in it with the same nile. 
Therefore, the class identifier component ofthe ESP would not know which logical output 

port the data packets with "source IP address - 111.11 1.111.111/16- should go out of. From 
this e)cample. it can be seen that .11 classes within all TP policies must be verified against 
each other to confirm that the CLT is ft^ of unresolvable conflict. Furthermore, h must also 

25 be confirmed that the information given to the flow identifier and traffic manager 
components must also be flw of conflicts. 

Like individual classes, each TP poUcy can be crerted. edited, committed (verified and 
saved), stored in a TP policy repositoiy. and then put into service at a termination point. This 
is sch«natically illustrated in Figure 10. In Figure 10. a TP policy "A" is created, edited. 

30 committed, and stored in a TP repositoiy 66. Once a TP policy has been committed, it can be 
put into service by "activating" it Activating a TP policy means associating it to a 
termination point. In Figure 10. a TP policy in the TP poUcy repository 66 is activated by 
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associating it with a t«mii«tion poiat <8. which in this case is an output port 70 of the ESP 

24. 

At the heart of the ESP 24, has a set of components that process data packets. This set of 
components is commonly refened to as the "logical packet processing pipeline" (or just 
S -pipeline-), which is schematically illustrated in Figure 1 1. As shown in Figure 11, » ESP 
may have six logical con^onents that handle packet processing: 

(DInooming Packet Managpr ("IPM"): This component uses part of the infonnation 
in a packet's header 36 to detenmne the next hop. 

(2) Route Identifier ("M"). This component detennincs which logical output port 

10 data packets will go out on. 

(3) Class Identifier C'CF): This component classifies data packets using the TP 

policy information. 

(4) Outgoing Packet Manager COPM"). This component physically stores data 
pack^s on the ESP 24 for outgoing purposes. 

1 5 (5) Flow Identifier CTF): This component identifies the flow to which a data 

packet belongs. 

(6) Traffic Manager ("TM"): This component uses the flow identifier results and 
the TP policy to schedule packets out of lo^cal output ports. 
In Figure 1 1, the components affected by policy management are shown in grey. In 
20 particular. TP policies affect the following: 

•tables used by the IPM (incoming IP packet fMOcessing); 
•the CLT used by the CI (incoming IP packet processing; 
•the flow tables used by the FI (outgoii^ IP packet processing); and 
•the traffic management tables used by the TM (outgoing IP packet processing). 
25 Figure 12 illustrates more clearly how a TP poUcy is applied to both incoming and 

outgoing dau packets. In the example in Figure 12: 

(1) a dau packet artives into the Ethernet Inteifece Card ("EIC) from the LAN 

20; 

(2) the CI on the EIC classifies the data packet using the compiled poUcy tree's 
30 identification information; 

(3) the IPM on the EIC deteraiinea using the TP poficy information the logical 

output port on which the data packet goes out; 
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(4) the FI on the ATM Interfkce Card (AIC) detennines the flow to which the data 
packet belongs using the compiled policy tree'e property or attribute infoimaticn; 

(5) the TM on the AIC schedules out the data packet using the policy tree property 

infonnation; and 
5 (6)the data packet leaves the AIC to the WAN 22. 

The IT poUcy infimnation must be distributed to the pipeline components affected by 
policy mwiagement (those shown in grey in Figure 11). In order to understand how to 
distribute the information to the pipeline components, a high level understanding of the ESP 
10 24 architecture is required. Figure 13 schematically iUustrates the organization of these 
logical pipeline components within the ESP 24. Figure 13 shows that the logical packet 
processing components are distributed among different cards, including main controller card 
74 and interface cards 76. 78. It also shows the propagation of policy information fiom a 
policy designer 72 to the particular logical packet processing components within the ESP 24. 

IS as follows:. 

(1) the TP policy designer 72 creates and commits a TP policy; 

(2) the TP policy is put into service; 

(3) the TP policy is processed; 

(4) the processed TP policy results are distributed to the interface cards 74, 76, 78. 
20 All cards contain a host processor CHP") where some form of element poUcy 

management will be done. The HP on the main controller card 74 manages the logical 
element policy functionality provided to users. It also processes the logical TP policies to an 
intermediate fbrm and propagates the results to the HPs on the interfiu* cards 76. 78. 
Specifically, the HP on the main controller card 74: 
25 (l)compiles the poUcy tree and generates the logical CLT that the a requires (since 

all interface cards require the CLT. the CLT is propagawd to all interfece cards 76, 

78); 

(2) using the TP-TP policy association information, generates the required table 
for IPM for the next hop lookup based on the class ID (since all interfiice cards 

30 requires this table, it is propagated to all interface cards 76, 78); and 

(3) using the flow and scheduling class property information, creates a Ust of flow 
identifier and scheduling update commands to incrementally change the flow tables 
and traffic manager tables (since not all the interfece cards require the same 

15 
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infonnatioiu the HP on the controller card determines which update commands should 
be propagated to a particular interface card). 
TP policy changes must be distributed to the ou^ut-processing element on the affected 
output inter&ce card and to the input-processing elements of all input intoiace cards. All 
S input inter&ce cards are affected by a TP policy change because the class identifier uses the 
TP policy information to classify incoming packets into specific service classes. The 
scheduling engine uses this same policy to map pacicets into flows and to sdiedule packets. 
The HP on the interfhce cards manages and propagates the processed policy information to 
the CI, IPM, FI and TM. Specifically, the HP on the interface cards will do the following: 
10 *&pply the appropriate table to the IPM and CI; 

•implement the appropriate update commands to incrementally change the flow tables 
managed by the FI; and 
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-implement the appropriate update commands to incrementally chaqge the 
traffic management tables managed by the TM 
Proper operation of the ESP 24 requires synchronizing the policy changes to the 
input and output-processing elements to minimize the impact of policy changes to 
5 traffic running through the ESP 24. To accomplish this goal, the ESP 24 supports 
incremental updates to its policies. Incremental updates to policies imply an inherent 
latency in completing a policy change. Although allowing abrupt policy change can 
reduce this inherent latency to near zero time, the traffic impact becomes less 
predictable. By using incremental policy updates, the ESP 24 balances the need to 
10 minimize traffic impacts caused by policy chaises with reducii^ the latency needed 
to complete a policy change. The changes should prefiarably be applied to the various 
pipeline engine tables in a specific order. 

When a class is deleted, the affected tables are updated in the following order: Q) 
classification tables; (ii) flow tables; and (iii) traffic management tables. When a 
1 5 class is added, the affected tables arc updated in the following order: (i) traffic 
management tables; (ii) flow tables; and (iii) classification tables. The order that 
tables are updated in response to class attribute (such as bandwidth or flow limit) 
changes depend on the specific attributes being changed. During an incremental 
change, a TP policy may go throu^ an intermediate transitoiy period when the TP 
20 policy is not valid. The ESP 24 stnjctures its incremental changes to minimize the 
traffic impaas caused by these transitory TP policies. Figure 14 schematically 
illustrates how a new TP policy can be put into service over an existing TP policy 
using incremental changes. Figure 14 shows that to put this particular new TP policy 
into service, a sequence of incremental changes must be done. The period of time to 
25 perform the entire sequence of chaises is called the activation latency. 

In summary, the basic steps to activate a TP policy are as follows: 

(1) create the tables required for the CI and IFI^ 

(2) differentiate between the classes that are currently in service with the 
classes that will be put into service to create a list of PI and TM update 

30 commands; 

(3) distribute and synchronize the deleted classes by applying the tables 
and the ""delete"' commands; 

(4) distribute and synchronize the added classes by applying the tables and 
the "^add" commands; and 
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(5) distribute and synchroniie the modified classes by applying the tables 
and the "modify coinmaDds. 
As discussed above, a TP policy that is put into service must be verified against 
all cuirently in-service TP policies. In addition, a TP poUcy that will be put into 

5 service at a pre-detennined time in the fiilure must be verified against all TP poUcies 
that will be in-seivice at the same time. The action of putting a TP policy into service 
at a pre-determined time in the fiiture is called "scheduling". Scheduling a TP policy 
is a planning activity that determines what will happen in the future. Typically, 
scheduling policies can be made easier if there is a refisrence from which to use. One 

10 reference that can be made available is the history of when TP poUcies went into 
service. The history of the times when TP policies went irto service combined with 
statistics can provide useftil information to detennine which TP policies work well 
together during certain periods of time. For example. sUUstics may provide 
information that the traffic flow during Monday evenings were badly congested due to 

15 the TP policies, but the traffic flow during Tuesday evenings were fine. A check from 
the TP policy history could show that there were di£ferent TP policies active during 
Monday evenings than during Tuesday evenings. Tlie Tuesday evening TP poUcies 
could then be used on Monday evenings to see if the traffic flow in Mondays 
improves. 

20 The typical life cycle of a policy is as follows: 

(1) one or more classes are created according to the expected type of 

network services routed through the ESP 24; 

(2) one or more TP policies are created using new or existiiig classes 

and/or class sub-trees; 
25 (3) one or more TP policies are manually put into service; 

(4) another TP policy may be put into service manually or automatically 
(through a sdieduling mechanism); and 

(5) a class or TP policy may be deleted only if it is editable and not 
associated with the in-service TP policy. 

30 Preferred implememations of the invention mey include a computer system 

programmed to execute a method of the invention. The invention may also be 
provided in the form of a program product. The program product may comprise any 
medium which carries a srt of conqiuter-readable signals corresponding to 
instructions which, when run on a computer, cause the computer to execute a method 
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of the invention. The prograin product may be distributed in any of a wide variety of 
forms. The program product may comprise, for example, physical media such as 
floppy diskettes, CD ROMs, DVDs, hard disk drives, flash RAM or the like or 
transmission-type media such as digital or analog communication links. 

5 

The following describes a q>eciflc policy change characterization method and 
apparatus accordii^ to the invention. 

GLOSSARY 

1 0 aaitification A set of rules that xmiquely identify a set of packets. 

ESP Ent^rise Service Point- packet forwardii\g and QoS enforcement device. 
QoS Quality of service. 

QoS Requiranents The quality to give the classified packets. 

Class A class is a set of classification rules that identify padeets that belong to the 
IS class, QoS requirements, and other properties that specify how the packets will be 
forwarded out of the ESP. 

Rule Expression A rule that contains a set of orthogonal rule type expressions 
logically ANDed together. Orthogonal rule type expressions means that the rule type 
of each rule type expression shall not exist more than once in the rule expression. 

20 Policy A policy is a tree luerarchy of classes. 
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1 Introduction 

An ESP according to a currently preferred embodiment of the 
invention uses policies to control how packets are forwarded out each of its output 
logical poits. Each output logical port has its own policy. A policy consists of a tree 
5 of classes. 

Each class identifies a subset of packets passing through the ESP and 
specifies the treatment to be provided to those packets. Treatment may include one or 
more of QoS (e.g. bandwidth, delay, jitter, reliability), security (e.g. encryption), 
admission control (i.e. how many data connections will be allowed), and other types 
10 of packet forwarding treatment. 

A class identifies a subset of packets using one or more classification 
rules. A classification rule consists of one or more rule terms. Each rule term 
consists of two parts: the identity of a data item and a set of constant values. A data 
item may be a field in a received packet. A data item may be a value fi-om the 
15 environment in which the packet was received. The set of constant values can contain 
individual values, ranges of constant values, and, in the case of IP addresses, IP 
subnets expressed in CIDR notation. 

The data items supported by an may include, for example: 

• Souirce IP address (received packet's IP header) 

20 • Destination IP address (received padcet*s IP header) 

• TCP or UDP source port (received packet* s TCP or 

UDP header) 

• TCP or UDP destination port (received packet's TCP or 

UDP header) 

25 • ESP input logical port (environment) 

• Type Of Service (TOS) byte (aka Differentiated 
Services (DS) byte) (received packet's IP header) 

• Protocol (received packet's IP header) 

• TCP Ack Flag (received packet's TCP header) 

30 Additional data items may also be supported. All techniques described 

in this document are applicable to classification schemes supporting a different set of 
data items. 
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Each type of data item may be termed a classification dimension. A 
rule tenn is allowed to be missing from a clas^fication rule for any of the 
classification dimensions. A missing rule term is equivalent to a rule term that 
specifies the full legal range of values for the data item i.e. it specifies a wild card 
S dimension for the class. 

When a packet is received, classification rules are evaluated to classify 
the packet. If the value of the data item matches any of the constant values specified 
in a rule term, the rule term is considered to be satisfied. If all of the rule terms of a 
classification rule are satisfied, the classification rule is satisfied. If a mle is satisfied, 
10 the packet is considered to belong to the class to which the rule corresponds. 

It is usually an error for two or more loiles fi-om different classes to be 
satisfied by a single packet. Policy validation prevents this from occurring except in 
certain restriaed circumstances. 

As mentioned above a policy consists of a tree of classes. Packet 
1 5 classification takes place only in the lowest (leaQ classes. Packets can be viewed as 
entering the policy tree at the leaf class level. Packets percolate upwards through the 
tree until they reach the root of the tree. The root of the tree is associated with the 
data link attached to the output logical port. Packets leave the tree by being 
transmitted on the data link. 
2° Each class in the tree can specify treatment of packets. For example, 

each class will generally specify bandwidth. The bandwidth of each parent class must 
be equal to or greater than the sum of the bandwidth of all child classes. The root of 
the tree corresponds to the bandwidth of the data link. This allows the data link's 
bandwidth to be s^egated amongst classes of packets. 

Although packet dessification only takes place at the leaf class level, 
classification rules can be specified in higher classes. This is a convenience feature 
that provides a shorthand way of specifying common rules at higher levels of the tree. 

U'both a child class and its parent class contain rules, the ndes in the 
child class must match a subset of the packets that the rules in the parent class match. 
30 In other words, the child class rules must restrict or limit the parent class rules. 

The actual classification rules used in a leaf class are generated via rule 
compilation. Starting at the top of the class tree, rules are merged downwards to the 
leaf classes. The resulting merged rules are transformed into data structures that 
control the packet processing pipeline. 
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The packet processing pipeline will generally have packets queued for 
transmission on a data link. There are queues and waitii^ packets associated with 
each poUcy leaf class. New policies may be activated while the ESP is processing 
packets. When a new policy is activated, the new policy's class tree structure, 
5 classification rules, and packet treatment may be different from those of an existing 
poUcy. To put the new policy into effect the ESP may need to delete queues, add 
queues^ reassign queues to various leaf classes during the transition from the old 
policy to the new policy. 

Given the disruption that can occur, it is highly desirable to minimize 
10 the amount of change in the packet processing pipeline. Since policy changes 

normally only involve one or two dasses out of potentially many classes, the inventor 
has determined thai there is an excellent opportunity to minimize the amount of 
disruption if the unchanged classes can be identified. 

As it turns out, changes in packet treatment can be acconmiodated 
15 without much disruption. It is classification rule changes and class tree structure 
changes that cause the most disruption in the packet processing pipeline. 

This invention provides a strategy for determining the difiference 
between two policies. The differentiation process is used to determine the minimum 
number of changes that are required to replace an old policy with a new policy. 
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2 Policy Overview 

For the purpose of this document, a class can be considered to 
con^rise the following components: 

• Classification Rules 
S « QoS Requirements 

2.1 ClassHicmtlon 

Classification mles are described above. 

For the purpose of the techniques described in this document, it is 
usefiil to introduce the concept of a classification mask. A cl^gMfiWtion mM^ is bit 
10 mask that specifies which dimensions are specified by the terms of a classification 
rule or rules. The mask may be, for example. 8 bits in length covering the 8 
dimensions of classification (source IP address, destination IP address, source 
TCPAJDP port, destination TCP/UDP port, protocol, incoming logical port, TOS/DS 
byte, and TCP Ack flag). 
1 s The following is the mask: 

Bit 0: source IP address 
Bit 1 : destination IP address 
Bit 2: source TCP/UDP port 
Bit 3: destination TCP/UDP port 
20 Bit 4: incoming logical port 

Bit 5: TOS/DS byte 
Bit 6: protocol 
Bit 7: TCP Ack flag 
If bit 0 in the mask is set to 1, there is a rule term for source IP address 
25 in the classification rules, otherwise, if bit 0 in the mask is set to 0, there is no source 
IP address rule term. 

The following is a diagram showing the classification bit mask: 
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Figure IS: Qassification Mask 



Page 23 



11/24/00 FRI 23:38 [TX/RX NO 5338] 12038 



>l>24/pd Fkl 20:54 FAX 604 881 4081ca O23268TrTO0O- 1 1 -24 

For example, if the mask is 19, the binary version of this is 1001 1, bits 
0, 1 and 4 are set. This means that the classification rule: 

• specifies source IP address, destination IP address and incoming 
logical port 

5 • does not spedfy source TCP/UDP port, destination TCPAJDP port, 

TOS/DS byte, protocol, or TCP Ack flag i.e. any value is acceptable 

The ESP performs longest prefix matching for the two IP address 
dimensions. For other dimensions, a more specific range or values fiiliy contained in 
a less specific range is given preference. 



10 



Classification Rule CompOatton 



The ESP uses a classification engine in the packet processing pipeline 
to classify packets. The classification engine compares the packet header and 
1 5 environment data items with rules associated with leaf classes. To deploy a new 
policy, it is necessary to compile the classification rules into a form that the 
classification engine can use. This involves the mergit^ of rules from parent classes 
down into chUd classes unless a child class overrides a parent class rule with a more 
specific rule. 

Figure 16 is a diagram showing a very simple form of rule 

compilation. 



Rules In Clam, must be 
merged Into Om^ and 



TNdal«ohWen«wllh 
ClsBB^ Clessg and 




Onca the perent aase rules ere merged to the 
leaf dassss, the ntles must be expanded out 

for the aaasjficsiion En0lne. 

Figure 16: Class Rule Compilation (Basics) 
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For example, suppose there were two trees that looked like the one in 

Figure 16. In the first tree, suppose: 

T^j. ClassA rule, source IP = 1.0.0.0/24 
JVeei. Classc rule: desdnation IP - 2.0.0.0/24 
5 7>eej, Classc compiled rule: source IP = 1.0.0.0/24. destination IP - 2.0.0.0/24 

Now suppose the second tree's had: 

7>e«A ClassA rule: destination IP « 2.0.0.0/24 

Treea, Classc rule: source IP - 1.0.0.0/24 
Th!e2, Classc compihdrule: source IP - 1.0.0.0/24. destination IP = 2.0.0.0/24 
10 Notice that both the first and second tree's Classc have the same 

compiled rule, but the rule in CUssa and Classc in both trees were different. The 
classification engine only cares about the compiled nile for each leaf class. Therefore, 
the classification rules of Classc in both trees are the same. 

2.2 Rutos for Compilation 

15 Policy management requires each child's rules to be more restricted 

than ks parent's rules. If a dimension of a child's rule is not a subset of the same 
dimension of its parent's rule, then an error has occurred. Child rales ahwiys take 
precedent over parent rules. As a result, the child rule is always used when parent and 
child rules are merged. For example: 

20 Parent Rule: Source IP-1.0.0.0/24. 2.0.0.0/24 
rhiidRuie: SnnrggIP=i.o.0.y?2 ^ 

Merged Rule At Child: Source IP= 1 .0.0.2/32 

The parent rule in the example means that packets can match a source 
25 IP addws of 1 .0.0.0/24 or 2.0.0.0/24. The child rules state that packets must match a 
source IP address of 1 .0.0.2/32. When the merge of parent with child occurs, all the 
child i^es prevail since the merge must be the largest subset between the two. which 
■vnil always be all the diild's rules. 

Note that if a value in a rule within a child is not a subnet of the 
30 parent's values, then an error has occurred and should be reported back to the user. 
For example: 

Parent Rule: Source IP-l.O.O.Q/24, 2.0.0.0/24 
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Merged Rule At Child: Source IP= <empty - efTaf> 

In this example, the source IP address of the child is not a subset of any 
of the parent values resulting in an error. 
5 If a parent rule is empty, it means all possible values are acceptable. If 

a child has rules in a dimension and the parent does not, then any value a child has is 
valid. For example: 

Parent Rule: Source IP" 

Child Rule: Sowryg l,0.P.2/32 . 

10 Merged Rule At Child: Source IP= 1.0.0.2/32 

Using this strategy reduces the parent classes to the child leaf classes 
by processing only similar dimension typea first. Once all the dimension types are 
processed, then the expansion of the rules can be done. 

2.3 Class Rule Compilation Notation 

IS The following shorthand notation is used in subsequent examples: 



20 



25 



30 



Shorihand For Dimension Types 
SIP=Source IP Subnet Value 
DlP^Destination IP Subnet Value 
SJP"Source port range Value 
DFHDestination port range Value 
IP=Incoming Port Identifier Value 
TOS-TOS/DS byte Vahie 
P*=Prctocol Value 

TCP=TCP Session Creation Flag Value 

So SIPi could mean 1.0.0.0/24 and SIP2 could mean 2,0,0.0/24. 

SItarthandFor Rules 
The table shows the class levels in rows. The columns are the dimensions. The 
values in each cell is the subscript value meaning a unique value of that dimension 
type: 

Sff Dff SP DP IP TPS 2 ICE. 



Class Rule aiUvell \ 1,2,3 1,2 1 1,2 
Class Rule at Level 2: 4,5 4.5 
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The above example table implies that there are two levels in the poli^. 


Each row represents the rxiles in a single class. In this case the rules are: 


Class Rule M Level 1: (SIP, | SIPj | SIP3) & (DIPi | DIP,) & (SPi) & (DP| | DP,) 


Class Rule at Level 2: (SIP4 


|SIP5)&(SP4|SPS)&(IP,) 


If: 




SIPi « 1.0.0.0/24 




SlPa = 2.0.0.0/24 




SIP3- 3.0.0.0/24 




DIPi= 4.0.0.0/24 




DIP2= S.0.0.0/24 




fflPi - 10-100 




DPi » 10-100 




DP2 = 200-300 




Then 






Class Rule at Level J : 




(SlP-1.0.0.0/24 1 SIP-2.0.0.0/24 1 SlP^3.0.0.0/24) & 




(DIP-4.0.0.0/24 1 DIP-S.0.0.0/24) & (SP*10-100) & 




(DP"10.100 1 DP-200.300) 



20 If Figure 17 is the diagram for this nile compilation example: 




Figure 17: Example Path In Policy To Compile 
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The table to compile this would look like the following: 



)043 





IP 


IP 


P 


P 


P 




OS 


CP 


ClassARule 


.2.3 


.2 




,2 










Clas$B Rule 


.5 




.3 












ClasscRule 



















10 



Table 1: Shorthand Compilation Table 

2.4 Bmtm Forcm Rule Compilation Mmthod 

The brute force mechanism performs the compilation process using the 
S following steps starting at the root dass: 

• Expand the parent rules into a set of basic rules. 

• Expand the diild rules into a set of basic rules. 

• Combine (logical AND) the parent basic rules and child basic rules. 

• Eliminate more general terms in &vour of more specific tenns. 

• Rqseat this process downwards through the class tree until the child 
class is a leaf class. 

This process requires more time than many users would be willing to 

tolerate. 

For example, if the following was given: 





IP 


P 


P 


P 




OS 


CP 


ClawARuIe 


.2 


.2 














ClassB Riile 



















15 



Table It Brute Force Compilation Example 

Then the conq)ilation would be as follows: 



20 



Expand the parent rules into a set of basic rules: 
(SIPi & DIPi A SPi & DPi) I (SIPi & DIP2 & SPx ft DPi) I (SIP2 ft DIPi ft SPj & 
DPi) 1 (SIP2 ft DIP2 ft SPi ft DPi) 

Next expand the child rules into a set pf basic rules : 
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20 
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(SIPj&SPa&Pi) ' 

Logically AND the parent and child basic rules: 
(SIP, & DIPi & SP, & DP, & SIP3 & SPa & Pi) I (SIP, & DIP, & SP, & DP, & SiP, 
& SP3 & Pi) I (SlPa & DIP, & SPi & DP, &. SlPa & SPj & P,) | (SIP, & DIPj & SP, 

&DPl&SIp3ftSP2&P,) 

Eliminate mare general terms in favour efmare specific terms . In Oris 
example, assume that SIPs is not a subset o/STPi but is a subset o/SlPj andSPsisa 
subset of SP]-. 

(DIP, & DP, & SIPj & SPa & P,) I (DIP2 & DP, & SIP, & SP, & P,) 



If SIP3 were not a subset of SIP, or SIPi then the set would be empty. 

Notice that when the child lules were compiled in with the parent 
mles, whenever there was a specified child dimension, the child dimension essentially 
eliminated the parent dimension values. This will always be the case and is the basis 
of the next conipilation method. 

2.5 Improved Ruto Compilation Mathod 

A better technique for compiling rules takes advantage of rule 
diminalion (shown in a previous section). 

Hie technique processes a pair of parent-diild rules at a time. 
Specifically, compile the root and its child to get a new set of rules. Then compile the 
resulting rules with the next child's rules. Note that the niles are not expanded out to 
their basic rules until the leaf child has been reached. 

When compiling parent and child mles together, terms for each 
dimension are processed separately. Logically AND the teims for each dimension 
together to create a new rule. When doing this, the only check that needs to be done 
to ensure each child rule term is a subset of at least one parent nAc terra of the same 
dimension. If this check succeeds, then the new rule generated will simply contain all 
the child rule terms. 

Consider the example in the bmte force section: 



IS 




IP 


IP 


p 


p 


p 




OS 


CP 


.2 
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ClassB Rule 

















Table 3: Rule Compilatioa Sumple 
Then the following would be done: 



ClassARule 


IP 


IP 


P 


P 


P 




OS 


CP 




.2 














ClasBB Rule 


















New Rule 




.2 















Table 4: New Rule Generation Example 

Notice that if the child rule terms are valid (meaning that all the child 
S rule terms are a subset of at least one of the parent rule tennsX then the child rule 
terms are always in the new rule expression, never the parent rule terms. 

If a child rule term is not a subset of any of its parent rule terms^ then 
an error has occurred and should be reported to the user. 

When the new rule at the child leaf class is finally created, then it can 
10 be eaqianded to its basic rules: 

(SIP3 & DIPi & SPs & DP] & Pi) I (SIP? & DlPa & SPa & DPl & Pi) 

Notice that this is the same result as the brute force method, but the 
technique was much 8inq>ler. 

If there were a class under Classa, th« the rules for the new child class 
15 would be combined with the New Rule generated by combining ClassA and ClassB 
before expanding to the basic rules. 
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3 Detection of Possible &|ulvalent Leaf Classes 

Once the rales are compiled in hoA policy trees, leaf classes are 
analyzed to detect possible equivalent leaf classes. 

It is inefficient to simply peifbrm a pairwise eontparison of classes in 
5 the old and new poUcy trees to see if their compiled classification rules are equivalent 
If each tree has approximately N classes, then each of N classes in the old policy roust 
be compared with up to N classes in the new policy. On average it will be necessary 
to examine N/2 classes in the new policy before a match is found. If classes in the 
new policy are marked as being part of a match then it will be necessaiy to e«iniine 
10 N/4 classes in the new policy on average. This results in a total of N'/4 dass 

comparisons. This assumes of course that the new policy is only a sUght modification 
of the old policy. If not, the absolute worse case of N» class comparisons may have to 
be performed only to find that theit are no matches. 

Instead it can be preferably to use a method whereby one only needs to 
completely process the classes in one of the trees. The logical choice would be the 
old policy tree since its classes are the ones that can be carried forward unehaqged 
into the new policy. As each class in the old policy tree is processed it would be 
preferable to have a method that would compare the class to only log N or fewer 
classes in the new policy tree. 

3-1 Log N Data Strueium Method 
One method for doing this is to define a comparison function that 
returns a result of less than, equals, or gn»ter than when it is provided with the 
dassification rules of two dasses to compare. The comparison function is used as the 
basis for inseiting all of the classes from the new policy tfee into a suitable data 
structure. An appropriate daU structure would be a binary tree, skip list, or the like 
that supports OOog N) insen and search performance The result is that all of the 
classes fiom the new policy tree are sorted in the order dictated by the chosen 
comparison function. 

Proceeding in an iterative manner, each class ftom the old policy is 
compared with the dasses in the data structure in order to identify a dass fiom the 
new policy with equivalent dassification rules. Because the data structure supports 



25 



30 
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O(logN) searching, identifiGation of equivalent leaf classes should be acconqilishcd 
with performance of 0(N log N). 

3.1.1 Rule Pre-Processing 

Determination of classification rule equality will be eased if the 
S classification rules of each class are pre-processed to maximize correspondence and 
consistency. 

Rule terms should be simplified as much as possible. For example, if a 
rule contained two rule tenns for a single dimension, they should be coalesced into a 
single term. Ifa rule tenn contains multiple constant yahies/ranges, adjacent or 
10 overlapping values should be merged into a single constant range value. 

If a class has multiple rules, some basis shoidd be chosen for sotting 
the rules. This allows corresponding rules of two classes to be easily compared. 

3.1.2 Comparison Functions 

The chosen comparison function must be able to accurately determine 
15 that the classification rules of two classes are equal. Other than equality, an arbitrary 
basis can be used to determine that the rules of one class are less than or greater than 
the rules of the other dass. 

One possible comparison ftmction for the rules of two classes A and B 
might be based on the following logic; 
20 1. Compare the number of rules each class has. If the number of rules is 

identical, continue with step 2. tf class A has fewer rules, return less than as the 
value of the fiinction. Otherwise return greater than. 

2. Compare the classification masks of corresponding rules. If each pair of rules 
has identical masks, continue with stqs 3. For the first mismatdiing pair of rules» 

25 if the binary value of mask A is less than the binary value of mask B. return less 
than as the value of the function, Othowise return greater than. 

3 . Compare the number of constant values/ranges in the source IP address tenns 
of corresponding rules. If each pair of rules has the same number of constant 
values/ranges, continue with step 4. For the first mismatching pair of rules, if rule 

30 A has fewer constant values/ranges, return less than as the value of the fiinction. 
Otherwise return greater than. 
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4. Compare the constant values/rangBS in the source n» address twins of 
coiresponding rules. If each pair of rules has the same constant values/nwges. 
continue with step S. For the tirst mismatching constant vahWrange in the first 
mismatching pair of niles, if the nile A constant value/range has a lesser value 

5 (constant value), lesser starting value (constant range), or lesser final value 

(constant range), return less than as the value of the function. Otherwise return 
greater than. 

5. Compare the number of constant values/ranges in the destination IP address 
terms of coiresponding rules. If each pair of rules has the same number of constant 
values/ranges, continue with Step 6. For the first mismatching pair of rales, if rale 
A has fewer constant vahies/ranges, return less than as the value of the fimction. 
Otherwise return greater than. 

6. Compare the constant values/ranges in the destination IP address terms of 
corresponding rales. If each pair of rales has the same constam vahies/ranges. 
continue with step 7. For the first mismatching constam value/range in the first 
mismatching pair of rales, if the rale A constant value/range has a lesser value 
(constant value), lesser starting value (constant ranged or lesser final value 
(constant range), return less than as the value of the fimction. Otherwise return 
greater than. 

20 7. Compare the number ofconstant values/ranges in the source TCP/UDP port 
tenns of corresponding rales. If each pair of rales has the same number of constant 
values/ranges, continue with step 8. For the first mismatching pair of rales, if rale 
A has fewer constant values/ranges, return less than as the value of the foncUoa 
Otherwise return greater than. 

25 8. Compare the constant values/ranges in the source TCP/UDP port terms of 
corresponding rales If each pair of rales has the same constant values/ranges, 
continue with step 9. Forthc first mismatching constant vahie/range in the first 
mismatching pair of rales, if the rule A constant value/i«nge has a lesser vahie 
(constam vahie), lesser starting value (constant range), or lesser final value 
(constant range), return less than as the value of the fimction. Otherwise rerarn 
greater than. 

9. Compare the number ofconstant values/ranges in the destination TCP/UDP 
port terms of corresponding rales. If each pair of rales has the same number of 
constant values/ranges, continue with step 10. For the first mismatching pair of 
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roles, if lule A has fewer constant values/rBnges, return less than as the value of the 
fiinction. Otherwise return greater than. 

10. Compare the constant values/lranges in the destination TCP/UEWP port tenns of 
corresponding rules. If each pair of tules has the same constant values/ranges; 
cominuewithBtep 11. For the first mismatching constant value/range in the first 
mismatching pair of rules, if the rule A constant value/nuige has a lesser value 
(constant vahie). lesser starting value (constant rangeX or lesser final value 
(constant range), return less than as the value of the fiinction. Otherwise return 
greater than. 

1 1 Compare the number of constant values/ranges in the protocol tenns of 
coiresponding rules. If each pair of rules has the same number of constant 
values/ranges, continue with step 12. For the first mismatching pair of rules, if rule 
A has fewer constant vakiesAanges. return less than as the value of the fiinction. 
Otherwise return greater than. 

12. Compare the constant values/ranges in the protocol terms of corresponding 
rules. If each pair of rules has the same constant vahiea/raiiges, continue with step 

13. For the first mismatching constant value/^ge in the first mismatching pair of 
rules, if the rule A constant value/range has a lesser value (constant vahie), lesser 
starting value (constant range), or lesser final value (constant range), return less 
than as the value of the fiwction. Otherwise return greater than. 

13. Compare the number of constant values/ranges in the TOS/DS byte terms of 
corresponding rules. If each pair of niles has the same number of constant 
values/ranges, continue with step 14. For the first mismatching pair of rules, if rule 
A has fewer constant values/ranges, renim less than as the value of the fiinction. 

25 Otherwise return greater than. 

14. Compare the constant values/ranges in the TOS/DS byte terms of 
coiresponding rules. If each pair of rules has the same constant values/ranges, 
continue with step 15. For the first mismatching constant vahie/nuige in the first 
mismatching pair of rules, if the rule A constant value/^ange has a lesser value 
(constant value), lesser starting vahie (constant range), or lesser final value 
(constant range), return less than as the value of the fiinction. Otherwise return 
greater than. 

15. Compare the constant values in the TCP Ack fiag terms of corresponding 
rules, ffeach pair of rules has the same constant values, continue with step 16. For 
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the first roismatching constant value in the first mismatching pair of mles> if the 
rule A constant value has a lesser value, return less than as the value of the 
fiinction. Otherwise return greater than. 

16. Compare the number of constant values/ranges in the iqiut logical port terms 
of corresponding rules. If each pair of rules has the same number of constant 
values/ranges, continue with step 17. For the first mismatching pair of rules, if rule 
A has fewer constant values/ranges, return less than as the value of the function. 
Otherwise return greater than. 

17. Compare the constant valuesfranges in the input logical port terms of 
corresponding rules. If each pair of rules has the same constant values/ranges, 
continue with step 18. For the first mismatching constant vahie/range in the first 
mismatching pair of rules, if the rvie A constant value/iange has a lesser vahie 
(constant value), lesser starting value (constant range), or lesser final value 
(constant range), return less than as the value of the function. Otherwise return 

13 greater than. 

18. Return equals as the value of fimction. 

3.2 Hash Tmbl9 Method 

An alternative method for identifying possible equivalent leaf class 
pairs uses a hash table. This method can provide better performance. 

A hash function is chosen that generates a bash index based on many 
of the parameters used in the comparison fimction described above. The hash index is 
used to index into a hash table that is several times larger than the expected number of 
classes. If the chosen hash fiinction has good uniformity, there will be voy few 
collisions. 

The classes firom the new policy are inserted into the hash table. 
Iterating over the classes in the old policy, the hash index is calculated. If the hash 
index of a class in the old policy tree corresponds to the hash index of a class in the 
new policy tree, a detailed comparison of the classification rules of the bvo classes is 
performed. A variant of the above comparison function that only tests for equality 
30 could be used. 

Use of a hash table method should provide 0(N) performance. 
The chosen hash fonction should keep in mind that real-life 
classification rules are more likely to include terms for the source IP address. 
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destination IP address, source TCPAJDP port, destiiHtion TCPAJDP port, and 
protocol dimensions tfian odier dimensbns. Clustering of source and destination IP 
addresses will be seen. Clustering of quantities of constant values/ranges will also be 
seen. 
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4 Policy Olfforentlation 

The ESP classification engine is not concerned wth the structure of 
paroit classes above the leaf classes. It is only concerned with the compiled rules for 
each leaf class. 

5 However, the ESP packet scheduler cares about the structure of 

classes, because its packet handling mirrors the tree structure. To generate the data 
smictures that will control the packet scheduler, it is stroi^y preferred that we find 
the minimum set of charges that will transform the old data structures into the new 
structures. Class adds and deletes cause the most disruption in the packet processing 
10 pipeline whereas class changes and class equivalencies cause little or no disruption to 
the ruxming packet pipeline. 

If the packet treatment of a class is changed, it can be handled by a 
class change, because this only requires that parameters in the existing data structure 
be modified. 

1^ If the classification rules of a class change, the class in the old policy 

must be completely deleted and the revised class added to the new tree. This is 
because packets queued in the old class may not satisfy the new classification rules. 
Classification rule changes only aflTect the pack^ scheduler for leaf classes, since it is 
not aware of any rules existing for non-leaf classes. 

2^ The focus of policy differentiation must be to identify incon^atible 

changes in leaf class classification rules. As will be seen in the next section, 
structural considerations such as tree depth also come into play. 

4.1 Pmmnt Unngm Rales 

The packet scheduler's packet processing data structures mirror the 
25 structure of the policy tree. The following rules concerning parent lineage must be 
satisfied if two leaf classes are to be considered equivalent: 

• the number of classes between leaf classes and the root 
must be identical 

• if a pair of leaf classes in the old policy is to be 

30 considered equivalent to a pair of leaf classes in the new policy, and either pair 

has the same parent class, the other pair must also have the same parent class 
As an example of applying these rules consider Figure 18: 
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Figure 18:Eiampie Parent Oau LiBcagc 

Assume the following: 

• Classp and Classj have the same set of compiled rules (nilesi) 
5 • Classo and CIsssk have the saine set of compiled rules (miesa) 

• ClassB and Classt have the same set of compiled rules (rulcsa) 

Notice the following parent class lineage: 
Classp: Classf -> Classc -> Classx 
Classo: ClassD CiassA 
10 ClassE. ClassB ClassA 

Classj: Classj ClassH 
Classx: ClassK -> Classn 
CiassL: ClassL -> Classi 
Applying the above rules: 
1 5 • Classp and Classj cannot be the same since Classp has two parents to the root 
whereas Classj has one 

• ClassD and ClassK can be considered the same since they both have one parent 
to the root. 

• CiasSE and ClassL cannot be considered the same even though both only have 
20 one parent to the root. This is because: 

ClassD and ClasSK have already been designated to be the same 
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ClassD and Class^ have the same parent 
ClassK and C]as9L do not have the same parent. 

For ClassE and Classt to be the same, CIbssl must have be a 
child of ClassR. 

S Note that if Classs and ClassL were considered to be the same, then 

ClasBD and ClassK could not be considered the same fisr the same reason. 

4,2 Determlntng Parent Une^e Equality 
Only those leaf classes that have the same compiled classification rules 
need to be checked for parent lineage equality. 
10 Here are some further observations about parent lineage equality: 

• If two leaf classes are to be considered equivalent, their comply parent 
lineage must be considered equivalent. 

• In situations where it is ambiguous as to which parent classes are to be 
considered equivalent, the ambiguity should be resolved in favour of the parent 

1 5 that maximizes the number of equivalent leaf classes. 

An example of the second observation can be considered with 
reference to Figure 19. 




Figure 19: Parent Class Lineage Determination 

The structure of the two policies is as follows: 
20 • Classc, ClassD and Classs are under the same ClassA 

• Classp and Classo are under the same Classa 

• ClasBj and ClassK and under the same ClassH 

• ClassL and ClassM are under the same Class] 
Assume the following: 
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• Classc has the same set of compiled rules as CIbsbs 

• Classo has the same set of compiled rules as CIsssk 

• ClassB has the same set of compiled mles as ClassL 

• Classp has the same set of compiled rules as ClassM 

5 Consider the possibility of making a final determination that Classy 

and ClassL arc equivalent. This would necessitate that ClassA and Classi be 
considered equivalent This would prevent the Classc - Classj and ClassD - ClassK 
equivalencies, because those equivalencies require that ClassA and ClassH be 
considered equivalent. Given our desire for minimal change, this ambiguity would be 
10 resolved by preferring the Classc- Classj and Classn- Classx equivalencies. 

4.3 Bquhnlmtt Pannt UnBoge Dmtermtnation 

Technique 

To find equivalent parent lineage; iterate downwards through the levels 
of the two policy trees, starting at the root, and find the most matching sets of leaf 
1 5 classes under the classes at the given level. 

A level iteration discards leaf classes that do not have the same paitmt 
lineage at that level, but will keep the best matching leaf classes. 
This is done by: 

• Before iterating, number each of the classes in both trees. 

• ^'Jnd the pairs of leaf classes (a pair consists of a leaf class from one 
policy tree and a leaf class from the other policy tree) that have the same set of 
compiled rules (see 2.5), 

• Iterate downwards through the levels of classes in both policy trees 
(note that there is no need to iterate over the leaf class level, since it will not 

2S be a parent of any classes) 

o For each node at the given level, assign to the node all 
descendant leaf classes that arc equivalent to leaf classes in the other 
policy tree 

o Iteratively find pairs of nodes, one in each tree, at the given 
level that share the greatest number of equivalent leaf class pairs. 
Consider this pair of nodes to be equivalent and remove it and their 
assigned leaf classes from consideration. Continue iterating until there 
are no more nodes with assigned leaf classes. 
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o For any leaf class that has been assigned to one of the nodes, 
and the equivalent leaf class has not been assigned to the other node, 
drop that equivalent leaf class pair from future consideration as an 
equivalent leaf class pair. 



4.3. 1 Class Numbering 
Consider the two policies shown in Figure 20. 




Figure 20: Parent Qaas Lineage Technique Example 

Figure 20 has the classes and policies numbered as specified above. 



4.3.2 Finding Matching Class Pairs 
10 The next step is the find the pairs of leaf classes that have the same set of compiled 
rules. Assume the following for this step: 

Set of compiled lules in Classn = Set of compiled roles in Ciassaj 
Set of compiled rules in Cla5S9 = Set of compiled rules in Classas 
Set of compiled rules in Classw « Set of compiled rules in Ciassas 
15 Set of conq)iled rules in Classu = Set of compiled rules in Class24 

Set of compiled rules in Classr = Set of compiled rules in Classjs 
Set of compiled rules in CJassg - Set of compiled rules in Classes 
So the equivalent leaf classes are: 

KM 

20 in 

Eli 

Pctge4l 
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4.3.3 Level Iteration 
The next step is to iterate over the levels. Specifically: 

• The root level would consist of finding all the leaf classes under root© 
and rooti9. 

• The next level would be to find the leaf classes under Classi, CIaas2, 
Classjo. Classji and Class». 

• The last level would be to find the leaf classes under Classs, Class* 
Ciasss, Classfi. Clasgzs and Classas. 

Consider the level grouping of Table 5: 



Root Level 


Rooto 


R00tx9 


7,8.9. 10, 11. 12 


24. 28, 29, 32, 33, 35 


2"^ Level 


7.8 9.10,11,12 


24. 32, 33, 35 28. 29 


3"* Level 


9,10.11 12 


32 33, 35 



10 



15 



Table S: equivalent Leaf Cl$g$ Groups 
What this table indicates the groups of class assignments to a common 
parent. Specifically: 

• Classes {7, 8. 9. 10. 1 1. laj have a common parent at the root level 
(Rooto) 

Classes ^ have a common parent at the 2°* level (Classj) 
Classes P. 10. 11. 121 have a common parent at the 2"* level (Classi) 



20 



Classes P. 10. Ill have a common parent at the 3"* level (Classs) 
Class |l| has a parent at the 3"* level (Class4) 
Classes [24. 28. 29. 32. 3373^ have a common parent at the root level 



(Rootw) 



Classes |24. 32. 33. 3^ have a common parent at the 2"* level (Ckssn) 
Classes 128.2^ have a common parent at the 2"* level (Classu) 
Class H has a parent at the 3"* level (Classss) 
Classes t33.3d have a common parent at the 3" level (Classts) 
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4.3.3. 1 Matching Nodes at Each Level of Iteration 
At each of the levels^ the pairs of nodes sharing the most equivalent 
leaf class pairs are found. The equivalent leaf class nodes conesponding to unshared 
leaf classes assigned to the nodes are discarded. 

For example, the following leaf classes are assigned to the two root 



nodes: 



10 



15 



25 



r7,8.9, 10. ll."l3 toRo0ta 
j24, 28. 29, 32. 33, SSl toRoot 



Each of the six leaf classes on the left is equivalem to one of the six 
leaf classes on the right. For example. Class,, has the same set of compiled rules as 
Clas«33. There are no unmatched leaf classes. This will always be true of the root 
node, so we can conclude that downwards iteration through the policy tt«e can start at 
the level below the root nodes. The only reason for including the root nodes would be 
if a tree were allowed to have multiple root nodes. 

At the second level, the leaf classes are assigned to second level nodes 
as follows: 

QtoClassa 
$. 10.11. 12l to Class. 
124. 3Z 33,3Sf to Clasiao 
20 128.291 to Class«» 

The pair of nodes with the greatest number of equivalent leaf classes in 
common is Classi and Classijo followed by Classi and Classa: 

fTjiland gSrigl 



All of the leaf classes assigned to each node are associated with an 
equivalent leaf class assigned to the other node of the respective pairs, so nothing is 
discarded at this level either. 

Consider the third level assignments: 
R 10. Ul toClaas^ 



3° (^toClas84 

^toClass23 
H3.3Sl toClass»« 
The best pairing of nodes is Cla8S3 and Classjs: 
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10 



15 



20 



Of these five classes. and ^joJSj are equivalent leaf class pairs. 
This leaves Class,, that can't be matched up, because its equivalent leaf class Qass,, 
is a descendant of a different third level node Classo- As a result the equivalent leaf 
class pair 111. 321 is eliminated as an equivalent leaf class pair. 

With all of these classes removed from consideration, the only class 
left is © so it can't be matched with anything. Since it can't be matched with 
Mything at the third level, the equivalent leaf class pair (12:24) is eUminated as an 
equivalent leaf class pair. 

The final result of matching is the determination that the following 
equivalent leaf class pairs have the same parent lineage and can considered unchanged 
or modified: 

OH 

They and their ancestor classes will be retained, and only modified, 
during deployment of the new policy. 

When equivalent leaf classes are resident at different levels in the old 
and new policy trees, they will always be eliminated. They may share the same 
parent classes down through the one leaf class of the pair that is resident at the higher 
level in either the old or new tree. When iteration reaches the lower leaf class of the 
pair however, the higher leaf class will ao longer be shown as being associated with 
any node in the other tree at the deeper level, because no node at the deeper level in 
25 the other tree can have the higher node as a descendant. This will always result in the 
pair being eliminated, if they are not eUminated for other reasons. 

4.3.3.2 Array-Based Node Matching Technique 
Another technique for finding the best matching pairs of nodes 

involves: 

30 1 . start with the second level of the old and new policy trees. 

2. Create an empty array with one row for each node in the old policy tree at the 
current level and one cohunn fiir each node in the new poKqr tree u the current 
level. 
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3 . Put the number of equivalent leaf class pairs shared by each pair of nodes in 
the old and new policy trees at the current level into the matrix. 

4. Find the entry with the highest number in the matrix 

5. Once that number is found, the corresponding pair of nodes is deemed to 
match 

6. Eliminate the row and cohimn from the matrix containing the entry with the 
highest number 

7. Repeat steps 4 through 6 until either the matrix disappears (ail roivs and 
columns have been eliminated) or all entries contain 0. 

8. Repeat steps 2 through 7 for each level of the old and new policy trees where 
one of the trees has at least one lower level i.e. do not perform these steps for the 
lowest level of the deepest tree. 

In the above example, the following table was given: 





Rootb 


RoOtji9 


□at Level 


7,8.9, 10; 11, 12 


24, 28. 29, 32, 33. 
35 




7,8 9.10.11, 


24, 32, 33, 35 


""Level 


12 


2S,29 


"* Level 


9, 10, 11 12 


32 33, 35 



IS 



20 



Table 6: Equhralcot Leaf Class Groups 

From before, this table indicates the groups of class assignments to a 
common parent: 

• Classes r7. 8. 9. 10. 11. 12| have a common parent at the root level 
(Rooto) 

• Classra 53 have a common parent at the 2^ level (CIas52) 

• Classes |9, 10, 11. 1^ have a common parent at the 2"^ level (Classi) 

• Classes |9. 10, l l] have a common parent at the 3"* level (Classa) 

• Class [l§ has a parent at the 3"" level (Class4) 
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• Classes |24, 28. 29. 32. 33, 3S| have a common parent at the root level 
(Root,,) 

• Classes {24, 32, 33. 3"^ have a common parent at the 2^^ level (Class^o) 

• Classes 128. 29| have a common parent at the 2°^ level (Classaa) 

• Class ^ has a parent at the 3"" level (Classzs) 

• Classes ^3. 35| have a common parent at the 3"" level (Classis) 
As mentioned in the summary of the algorithm, each level must be processed 
separately. At the second level a matrix is created for the five nodes in the old and 
new policy trees: 





ClasBio 


Classsi 


Class22 


Classi 


4 


0 


0 


Classj 


0 


0 


2 



10 



15 



20 



2S 



Table 7: Second Level Matrix 
Claasi and Classao share the equivalent leaf class pairs: 

EM 



so their entry in the array has a value of 4. Similariy, Classj and 
C18SB22 share the equivalent leaf dass pairs: 

EH 
EE 

so their entry in the array has a value of 2. As there are only 6 
equivalent leaf class pairs, all other array entries are 0. 

The next step is to find die largest value in this matrix. In this case the 
value is 4, so ClasSi and Classao are designated as being equivalent. The Classi row 
and the Classia column of the matrix are eliminated to leave: 





Classsi 


CIass22 


Classy 


0 


2 
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Table 8: Reviled Second Level Matrix 

The next largest value is 2, so Classz and Classaa arc designated as 
being equivalent. Once the Classj row and the Classaa column have been eliminated, 
the matrix has disappeared, so level 2 of the policy trees has been completed. 
At the third level, the following matrix is created: 





Class33 


Class23 


Classs 


1 


2 


Cl88a4 


0 


0 


Classj 


0 


0 




0 


0 



Table 9: Third I^el Matrix 
Clas83 and Classu share the equivalent leaf class pairs: 

while Classs and Classjs share the equivalent leaf class pairs: 

KM 

KM 

Notice that the other three equivalent leaf class pairs are not 
represented in the level 3 matrix. This is because Class? and Classg in the old policy 
tree and Classw, ClasszK, and Class29 in the new policy tree reside at level 3 and arc 
not children of level 3 classes. 

The largest value in this matrix is the value 4, so Classa and Class25 are designated as 



being equivalent. The equivalent leaf class pair |il.32| shared by Class3 and C]ass23 is 
eliminated from consideration as an equivalent leaf class pair. The Classs row and the 
Class3s colmnn of the matrix are eliminated to leave; 





Classu 


Class4 


0 


Classs 


0 


Class6 


0 



20 



Table 10: Revised Third Level Matrix 
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Since there are no non-zero entries* the third level has been completed. 
The fourth level of the old and new policy trees consist only of leaf classes, so the 
overall method has also finished. 

It will be noticed that this method conflnms the equivalency of 
5 equivalem leaf dass pairs as a side effect of selecting an array cntiy with the highest 
value. 

It may also be noticed that the matrix method does not detect 
equivalent leaf classes that are at different levels of the old and new policy trees. If 
the matrix method is used, these leaf classes can be eliminated either by a simple 
10 comparison of tree level when they are first proposed as being equivalent (e,g. by 
incorporating policy level into the comparison function or hash fimction), or they can 
be detected as a side effect of constructing array entries. 

Marking Classes as being Modified, Unchanged, Added Or Deleted 
The pre^ous section showed how equivalent ancestor dasses are 
IS identified and how proposed equivalent leaf class pairs are confirmed as being 
equivalent or are diminated as being equivalent. Once the above step has been 
completed, the next step is to mark each dass in both policy trees as: 

• Unchanged 
Modified 

20 « Added 

• Deleted 

All equivalent ancestor classes and confirmed equivalent leaf classes 
found by the methods of the previous section are marked as being either unchanged or 
modified. The choice of marking these dasses as either unchanged or modified 
25 depends on whether a pairwise comparison of equivalent classes indicates whether 
they have any differences. 

Consider the same two policies that were used as an example in the 
previous section. Using cither of the methods in that section it was discovered that 
the following classes were equivalem: 
30 • Rooto and Rooti^ 

• Classi and Classao 

• Classi and Classn 

• Class? and Class35 
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Class? and Classn 
Classi and Class29 
CIass9 and Cla$a» 
Classio and Classjj 




10 



15 



Figurall: Marking Classea As Modified 

A class with (M) indicates that it has been marked as modified. If 
equivalent classes were truly identical, they would be marked as unchained instead. 

As a side effect of marking equivalent classes as being modified or 
unchanged, the class identifiers for the class In the old policy tree will be reused for 
the equivalent class in the new poUcy tree. The class idcntifien identify data structure 
entries for classes in the classification eqgine and packet scheduler. It is important to 
reuse the class identifiers to minimize the disrupHon of converting fiom the old policy 
tree to the new policy tree. 

The next step is to mark the rest of the old policy as being deleted: 
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Figure 22: Marking Clusea As Deleted 
A class with (D) indicates that it has been marked as deleted. 
The next step is to mark the rest of the new policy as being added as 
shown in figure 23: 

Figure 23: Marking Qasscs As Added 




A class with (A) indicates that is has been marked as added. 
It should be noted that the example resulted in relatively few classes 
being marked as modified or unchanged. In practical network situations, policies tend 
to evolve as a series of minor changes. The differences between an old and new 
10 policy tend to be minor. The overall policy difiFcreutiation method described in this 
document is quite valuable for minimizing the amount of disruptive changes in 
transitioning from the old policy to the new policy. 

As will be apparent to those skilled in the art in the light of the 
forgoing disclosure, many alterations and modifications arc possible in the practice 
IS of this invention without departing from ttie spirit or scope thereof. 
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